-
Notifications
You must be signed in to change notification settings - Fork 419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Create ELF Fieldset - Stage 2 Proposal #1294
Conversation
Co-authored-by: Eric Beahan <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's still the outstanding concern of how to best capture the expected structure of elf.imports
.
Defining elf.imports
as flattened is straight-forward:
PUT example
{
"mappings": {
"properties": {
"elf": {
"properties": {
"imports": {
"type": "flattened"
}
}
}
}
}
}
The outstanding item is what to do about elf.imports.name
and elf.imports.type
. We cannot explicitly define them underneath imports
in the index; Elasticsearch will throw an exception:
"reason" : "unknown parameter [properties] on mapper [imports] of type [flattened]"
We've taken an approach before with objects, like dns.answer
, where the docs have the top-level dns.answer
field and the expected sub-keys (like dns.answers.class
) listed as separate fields. I don't think that approach makes sense for flattened
though since there are not actual field mappings associated with each sub-field.
I think our best approach would be describing the expected structure of elf.imports
in the field's description. Something like
description: >
description text....
`elf.imports` expects the following object structure:
{
"imports": {
"name": "value",
"type": "value"
}
}
Whatever's decided, we need to add elf.imports
to the field definitions. I also made a couple of other notes.
Co-authored-by: Eric Beahan <[email protected]>
I just addressed this, please LMK if that meets your concern. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Andy, thanks for taking some time to address my questions offline and thanks to both yourself and Eric for your diligence with this RFC. Defining name and type field values should be sufficient to make the elf.imports mappings usable, without going too deeply into the weeds.
Just pinging to get a 2/2 review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay.
Spotted a few items on a final read-through, but otherwise everything looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@devonakerr @peasead @dcode I know we paused on the work around the Do we feel comfortable with how these fields are defined now? Are there any reservations for moving to stage 3 and having these fields moving from beta to GA in the schema? |
I don't see any outstanding concerns in this Issue; so we can probably move this to Stage 3. |
Is there a new sponsor or would you like me to move this? |
@peasead if you're okay opening the stage 3 PR and if @devonakerr is okay with continuing to sponsor, that'd be great! |
I heed the call. |
make test
? Yesmake
and committed those changes? YesPreview of markdown proposal